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SUMMARY & CONCLUSIONS 

Presented are a number of important experiences gained 
and lessons learned from the collaboration of the National 
Aeronautics and Space Administration (NASA) and the 
Japanese Aerospace Exploration Agency (JAXA) on the 
CoNNeCT (Communications, Navigation, and Networking re- 
Configurable Testbed) project. Both space agencies worked 
on the CoNNeCT Project to design, assemble, test, integrate, 
and launch a communications testbed facility mounted onto 
the International Space Station (ISS) truss. At the 2012 
RAMS, two papers about CoNNeCT were presented: one on 
Ground Support Equipment Reliability & System Safety, and 
the other one on combined application of System Safety & 
Reliability for the flight system. In addition to the logistics 
challenges present when two organizations are on the opposite 
side of the world, there is also a language barrier. The 
language barrier encompasses not only the different alphabet, 
it encompasses the social interactions; these were addressed 
by techniques presented in the paper. The differences in 
interpretation and application of Spaceflight Requirements 
will be discussed in this paper. Although many, but definitely 
not all, of JAXA’s Spaceflight Requirements were inspired by 
NASA, there were significant and critically important 
differences in how they were interpreted and applied. This 
paper intends to summarize which practices worked and which 
did not for an international collaborative effort so that future 
missions may benefit from our experiences. The CoNNeCT 
flight system has been successfully assembled, integrated, 
tested, shipped, launched and installed on the ISS without 
incident. This demonstrates that the steps taken to facilitate 
international understanding, communication, and coordination 
were successful and warrant discussion as lessons learned. 

1 INTRODUCTION 

The NASA has developed an on-orbit, adaptable. Software 
Defined Radio (SDR) and Space Telecommunications Radio 
System (STRS). It is a test-bed facility on the International 
Space Station. The CoNNeCT Project’s operational name for 


the flight system is the Space Communications and Navigation 
(SCaN) Testbed. The SCaN Testbed payload was launched on 
the Hope Transfer Vehicle # 3 (HTV -III) vehicle on July 21 st , 
2012 and was installed on the Express Logistics Carrier (ELC) 
3 at the P3 location on the International Space Station (ISS) 
two weeks later. Figure 1 shows the SCaN Testbed on the 
ELC 3 at the third port, P3, location on the ISS. The SCaN 
Testbed provides an adaptable SDR/ STRS based facility to 
conduct a suite of experiments to advance the SDR/STRS 
Standards, reduce risk by advancing the Technology 
Readiness Level (TRL) for spaceflight hardware and software, 
and demonstrate space communication links critical to future 
NASA missions. 



Figure 1: The SCaN Testbed on the ISS 


Now that the payload has been turned over to JAXA, 
integrated on the launch vehicle, launched, and installed, this 
paper focuses on the “big picture” lessons learned. Previous 
papers at the RAMS 2012 Symposium went into more detail 


on the specifics of both the flight payload design[l] and the 
ground support equipment[2]. Those papers go into more 
technical details whereas this paper is focused on the 
collaborations between the multiple NASA field centers and 
the multiple JAXA installations. For an overall view of the 
flight system, see Figure 2 which shows the SCaN 
Testbed/ExPA (ExPRESS Pallet Adapter), Radios and 
Infrastructure Components. 
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Figure 2: SCaN Testbed, ExPA, Radios and Infrastructure 


2 UNIQUE CHALLENGES IN WORKING WITH JAXA 


Because of the multi-center, multi -contractor, and multi- 
national nature of the design, assembly, integration, test, and 
launch of this spaceflight payload, many unique challenges 
had to be overcome. This paper focuses on the interactions of 
the multiple NASA centers, primarily the Glenn Research 
Center (GRC) and the Johnson Space Center (JSC), with the 
JAXA Tanegashima Space Center (TNSC) and Tsukuba Space 
Centers. Among the challenges were: differing languages, 
cultures, time zones, security, and communication formats. 

2.1 Language and Written Communications 

The most obvious challenge is the differences in the 
American and Japanese languages and alphabets. Whereas 
communications between the United States and French or 
Spanish speaking countries are eased by the shared basic Latin 
alphabet, the Japanese writing system uses three main scripts. 
These scripts are: kanji (Chinese characters), hiragana (for 
native words), and katakana (for foreign language, or loan, 
words). 


2.2 Cultural Differences 

Americans tend to be more casual and informal than the 
Japanese. In Japan, interactions are more purposeful and tend 
to have a socially prescribed order. For example, the 
exchange of business cards has a specific etiquette that should 
be followed as well as how team members are seated at a 
conference room table. Depending upon the rank of the 
parties and the formality of the engagement, bowing at 


greetings and departures may be deeper and longer. 

Because of these cultural differences, there are 
opportunities for misunderstandings during technical meetings 
or problem resolution meetings. 

2.3 Time Zones 

Japan is approximately half of the way around the world 
from Cleveland Ohio and Japan Standard Time (JST) is 13 
hours ahead of Cleveland Daylight Savings Time (EDST). 
When technical meetings and reviews are taking place in one 
country, the other is at rest. Simple phone calls must be 
planned and coordinated so that both parties are available. 
Furthermore weekends start earlier in Japan and of course end 
later for the US. 

2.4 ITAR/EAR Restrictions 

Because of the advanced technology employed in each of 
the 3 SDRs, they were treated as containing hardware that is 
specifically designed or can be modified as a “subsystem for a 
Spacecraft System or Associated Equipment article.” As such, 
the SDRs are designated by the State Department as being on 
the U.S. Munitions List (USML) XV (e & f), as defined in the 
International Traffic in Arms Regulations (ITAR), 22 CFR 
(Code of Federal Regulations) 120-130, and were export 
controlled. Having the flight payload classified as ITAR/EAR 
(Export Administration Regulations) caused extra precautions 
in handling not only the hardware but also the design and 
mission data associated with the hardware. Furthermore all 
written and verbal communications are controlled. 

2.5 Communication Formats 

While Japanese A size paper is identical to the 
International Standards Organization (ISO) A-series (with 
slightly different tolerances), the area of B-series paper is 1.5 
times that of the corresponding A-paper, so the length ratio is 
approximately 1.22 times the length of the corresponding A- 
series paper. Documents, drawings, presentations, etc. are 
typically presented in format and size that does not match with 
what a US engineer has in their folders, notebooks, and file 
cabinets. 

Furthermore, due to conflicting technologies, in most cases 
foreign phones will not work properly in Japan. For those 
phones that do function as they would back in the US, expect 
very high international usage fees. This becomes an issue 
when large parties visit Japan for technical meetings. 

For the SCaN Testbed the most significant communications 
challenge encountered was the difference in interpretation and 
verification of spaceflight requirements. The following 
section of the paper is dedicated just to this topic. 

3 INTERPRETA TIONAL DIFFERENCES 

The NASA SCaN Testbed team experienced the greatest 
challenges and thus opportunities for Lessons Learned when it 
worked on the interpretation of spaceflight requirements and 
their validation and verification with the JAXA team. The 
most interesting aspect to this is that many of the JAXA 
requirements have a NASA heritage but there were distinct 


differences in how each agency interpreted them. 

3.1 Project Requirements 

Project or Mission Requirements were mostly handled 
through interactions between NASA Headquarters (HQ), 
NASA GRC, the Jet Propulsion Laboratory (JPL), and NASA 
JSC. JAXA was informed of mission requirements as 
necessary to enhance their understanding of the overall 
mission of the payload that they were launching. Similarly, 
NASA was only informed superficially about the other JAXA 
payloads that shared the same HTV flight. Both NASA and 
JAXA understood that requirements and verifications that 
were not directly tied to the Safety & Mission Assurance 
Requirements, namely in the Safety and Reliability areas, 
were secondary and did not have to be distributed without a 
need to know. Indeed, some of these requirements were 
restricted by proprietary and/or ITAR/EAR limitations. 

3.2 Safety and Reliability Requirements 

System safety requirements typically address all phases of 
the mission, from ground processing and launch through on- 
orbit operations and decommissioning/disposal. Since SCaN 
Testbed was not to be operated on the ISS Japanese module, 
the JAXA safety requirements were applicable only for the 
ground processing through HTV separation from the launch 
vehicle. The JAXA safety requirements for design and 
processing were derived from the NASA payload safety 
requirements. The same documents as required by NASA 
were also mandatory for JAXA (hazard reports, safety data 
packages), and in addition they required unique safety 
compliance matrices. While a Preliminary Hazard Analysis 
(PHA) is common method for developing the safety 
assessment within safety data packages for NASA, it is not 
required to be submitted to the safety panel. JAXA required 
completion and submittal of the PHA as part of the total safety 
deliverable. 

With the exception of the ground processing at JAXA, 
reliability requirements were mostly tied to mission 
requirements and thus JAXA did not require direct 
submissions of reliability data related to flight. Where GRC’s 
reliability analysis was invaluable was in its application to 
avoiding ground processing, integration, and turnover 
problems at TNSC. Many of the TNSC ground processing 
hazards identified, entailed control and verifications methods 
that relied on certification to standards such as NASA-STD- 
5005C, the NASA Ground Support Equipment (GSE) 
Standard[3], The project’s approach to certification to these 
best practices and standards required the generation of: 
System Block Diagrams (SBD), PHAs, and Failure Modes and 
Effects Analysis (FMEA). Many of these SBDs, PHAs, and 
FMEAs had been generated for the ground processing at GRC 
and were directly applicable to TNSC because the same exact 
GSE was used. In fact, TNSC-specific analysis was very 
limited because of the project’s purposeful decision to use the 
same exact equipment to reduce variability. These hazard 
controls and verifications were submitted to JAXA for review 
and closure in SCaN Testbed’s formal Hazard Reports. The 


JAXA officials were satisfied with the project’s approach and 
approved all Hazard Reports without delving into the specific 
details of the SBD, PHAs, and FMEAs. More specific details 
on the project’s approach to reliability & system safety 
analysis, along with examples, are available in reference [2], 

3.3 Methodology and Practices 

With regard to safety processes, JAXA nominally has the 
same safety process as NASA and they are careful in 
following it. For example, when going through the NASA 
flight safety process, it has become acceptable for the NASA 
payload safety review panel to have the Phase III flight safety 
review months in advance of shipment to the launch site and 
for the project to come to the review with open action items. 
They are nominally closed to the safety verification tracking 
log and tracked to closure. JAXA does not operate in this 
manner for their ground/launch safety. They will not hold the 
Phase III ground /launch safety review until all verifications 
are closed with the exception of those to be closed at the 
launch facility. 

From our experience at the ground/launch safety reviews, 
JAXA performs a significant amount of evaluation prior to the 
actual review, such that the reviews themselves are short and 
concise. Reviews took at most half a day to conduct, versus a 
comparable flight review taking 1.5 to 2 days. Ground/launch 
reviews are conducted in person or via WebEx/telecom. They 
do not hold reviews solely out-of-board, such as what is 
usually done by NASA. 

JAXA has issued a summary presentation to explain what 
they expect for their safety process in addition to the guidance 
in their safety documents. 

4 PROBLEM RESOLUTION 

The challenges and issues stated above were addressed by 
multiple techniques. In reality, JAXA provided more 
contributions to addressing the language challenge than NASA 
did! Although a few members of the SCaN Testbed External 
Interfaces team learned the fundamentals of the Japanese 
language, the JAXA team was much more fluent in English 
than the NASA team was fluent in Japanese. Sticking points 
were handled by drawing pictures, pointing to drawings, or 
directing the JAXA team to NASA documents. 

Potential problems that could be based on cultural 
difference were addressed by a series of courses developed by 
the External Interfaces team for those personnel that would be 
traveling to Japan for the various engineering, safety review 
and turnover meetings. These 1 to 2 hour courses were based 
on lessons learned from previous visits to Japan, and NASA 
Kennedy Space Center (KSC) experiences during the 
integration and turnover of two HTV-II On-orbit Replaceable 
Unit (ORU) payloads at the TNSC. These series of courses 
were very effective because the Safety Review and Ground 
Integration Teams did not commit any major cultural blunders 
nor suffered cultural shocks during their trips to Japan. 

As expected, time zone differences were simply handled by 
either the SCaN Testbed team or the JAXA team shifting their 
work day to accommodate late teleconferences in their time 



zone that synchronized with the work day on the other side of 
the world. 

As the external communications Point of Contact (POC), 
the External Interfaces Team facilitated all communications & 
presentations between JAXA, NASA GRC and JSC. This 
allowed for consistent, focused and single -point- 

communications between the Project and JAXA. When 
project technical experts were required to interface with JAXA 
technical experts, this Team was involved in order to maintain 
continuity across all communications to both JAXA and the 
ISS Office. 

The External Interfaces Team was successful in performing 
the integration function by anticipating issues before they 
materialized by proactively working with the ISS Office and 
International Partners (Russian Space Agency, JAXA, 
Canadian Space Agency and European Space Agency) to 
work developing problems. 

The External Interfaces Team was integral in the 
development of all Safety Data Packages, the presentations to 
both JAXA and the ISS Safety Review Panels, and worked 
closely and early with the Extravehicular Activities (EVA) 
and the ISS and JAXA Extravehicular Robotics (EVR) Teams 
avoiding any problems with these critical functions. 

The relationships developed by the External Interfaces 
Team with key personnel at JAXA, KSC and ISS Office were 
critical in the success of the SCaN Testbed integration. The 
HTV exposed pallet was in co -development with the SCaN 
Testbed resulting in numerous discoveries in the analytical 
integration of the payload. This Team provided insight and 
forewarning into the imminent changes to carrier 
requirements, capabilities and limitations saving project 
resources in rework and potential unrecoverable interface 
problems. Furthermore they were able to negotiate non- 
standard services and hardware with JAXA, KSC and the ISS 
Office. 

The SCaN Testbed was the first Flight Releasable Adaptor 
Mechanism (FRAM) based payload to be integrated and 
launched at TNSC resulting in numerous discoveries 
throughout the physical and analytical integration. It was 
necessary to identify, obtain and provide at the launch site all 
required FRAM handling and critical lift equipment, 
procedures and required training to safely and efficiently 
integrate the SCaN Testbed. Among the problems resolved 
were: 

1. JAXA processes that were often not defined or 
unclear (e.g. safety, interface control, request for 
services) 

2. The physical and environmental boundary between 
the SCaN Testbed, FRAM, Passive FRAM and 
HTV’s cargo carrier platform 

3. Roles and responsibilities between JAXA, ISS 
Offices and the NASA GRC 

4. Communications between JAXA, ISS Offices and 
NASA GRC. 

Numerous logistical problems were resolved: because the 


cost to ship hardware to Japan is exorbitant, the team 
negotiated leaving all FRAM lift hardware at the launch site 
for future FRAM-based payloads and ORUs thus eliminating 
the need for any payload / ORU to ship lifting/handling 
hardware; installation and inspection procedures were 
developed and coordinated and provided to the ISS Office for 
future use; and the shipping container base was the payload 
work-stand, eliminating the need to ship a FRAM-based stand 
or performing unnecessary critical lifts of the SCaN Testbed. 

As the POC for all data transfers to JAXA, the Export 
License, packaging, shipment, Japanese Customs, inspections, 
un-packaging, ground handling, ground processing, turn-over, 
integration to the Exposed multipurpose Pallet, training and 
travel logistics for 15 travelers was managed by the External 
Interfaces Team. The documentation that accompanied each 
of these activities has been shared with the ISS for future use. 

International telephone service was addressed by pre- 
coordinating which team members were bringing their work 
cell phones, finding out if their phones worked in Japan, and if 
so, activating international service on those phones just for the 
travel period. Very few team members brought their personal 
phones with them; a high percentage of those that did 
experienced erratic phone behavior. 

During the 4 weeks of work in testing and preparing the 
payload for turnover at the TNSC site, the Ground Processing 
Team developed a successful work tempo to each work day. 
First, an early morning coordination meeting was held for the 
Team at the hotel where all the members were collocated. 
After arrival at the TNSC site, issues and problems were 
addressed directly between the SCaN Testbed’s JAXA Test 
Manager, and the JAXA’s NASA Interface lead, while both 
Agencies continued their respective work. Work was never 
called to a stop to address an issue/problem that required a 
large team wide meeting. Work was stopped, however, 
multiple times for lightning warnings in which case the entire 
facility had to be cleared for safety reasons. Figure 3 shows 
the NASA (right side of the picture) and JAXA (left side of 
the picture) Ground Processing Teams after the successful 
installation of the SCaN Testbed onto the HTV’s cargo carrier 
platform. 



Figure 3: SCaN Testbed Ground Processing Teams 


5 LESSONS LEARNED 

Although the intent of this paper is to pass on Lessons 
Learned to future international collaborative spaceflight 
missions, the CoNNeCT Project benefitted from the adoption 
of previous Lessons Learned. By observing the HTV-II 
ground processing, the External Interfaces Team conceived of 
a method to move the SCaN Testbed and Ground Support 
Equipment without assistance from JAXA eliminating 
significant coordination and ground-processing time. The 
inclusion of an HTV-IV Team member from KSC to observe 
and learn lessons from the SCaN Testbed’s ground processing 
at TNSC will increase the likely success of HTV-IV because 
the HTV-IV Team will adopt the SCaN Testbed’s 
methodology for the integration and ground processing of one 
payload and two ORUs. 

A series of Lessons Learned Workshops were held post 
turnover at the NASA GRC. These Workshops included 
inputs from all the NASA Field Centers involved with the 
SCaN Testbed. 

From the inception of the Ground/Launch safety process, 
there was misinterpretation of what data was needed (which 
forms to be completed) for the Phase O-I-II ground/launch 
safety review. Previous safety and reliability experience 
regarding flying hardware on HTV was, in retrospect, 
irrelevant, and lead to the provision of incomplete or missing 
data to JAXA. This caused confusion for JAXA and resulted 
in extra pressure for the whole team when attending the safety 
review in Japan. The lack of a direct interface to a JAXA 
safety and reliability counterpart to be able clarify 
requirements exacerbated this situation. The SCaN Testbed 
safety engineers were used to informal communication 
channels where they could call or e-mail someone on the 
NASA safety panel for information. Lesson Learned: It is 
important to have a clearly understood communication 
channel/process to allow for resolution of questions and issues 
prior to the JAXA safety reviews. 

Communication with JAXA is primarily through protocols 
and action items. As part of the learning process in working 
with JAXA, the team learned it needed to be clear in the 
agreements and understanding of what will be done by both 
parties (NASA and JAXA). JAXA requires this level of 
clarification. Lesson Learned: When working with JAXA, if 
agreements in work responsibilities or understanding of 
positions on topics is not captured in the protocols and action 
items, there can be confusion in what is expected to be 
completed (and when). 

SCaN Testbed also benefitted through the utilization of a 
well-defined verification and validation (V&V) process. 
Throughout the payload development after the Critical Design 
Review (CDR)/Phase II safety review, there were numerous 
verifications to be addressed - engineering, safety, program, 
carrier(s). Having a well-defined process was good for the 
work with JAXA, since they would not hold the Phase III 
ground/launch safety review without the required verifications 
completed. Lesson Learned: Having a defined verification 
and validation process made completion of processing all the 


verification requirements possible. But it was important that 
all parties that needed to weigh-in on the verifications were 
part of the process, otherwise the verifications had to be 
revisited and possibly redone. 

As mentioned in the Reliability Requirements section 
above, having a thorough, well documented, and configuration 
controlled set of reliability analysis is invaluable for avoiding 
“near misses” from a safety, reliability, and programmatic 
viewpoint. Although initially generated to satisfy NASA and 
project Reliability and Maintainability (R&M), and Safety 
Requirements, the SBD, PHA, and FMEA dataset was used 
later to satisfy JAXA R&M, and Safety ground processing 
requirements. 



Figure 4: Successful launch on H-IIB from TNSC 


Having stated the issues, problems, and lessons learned on 
this international collaborative effort, the most important fact 
to note is that the final result was a successful launch and 
installation on the ISS. Figure 4 shows the successful launch 
of the SCaN Testbed on the HTV-III carrier atop the H-IIB 
launch vehicle. 
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